From my upcoming book “Effective Remote Tech Teams”
to be published by Taylor and Francis.
Folksy wisdom — When we buy a drill, it is not because we need a drill, rather it is because we need a hole.
This is a question of craftsmanship. Agile is a tool. The work product is about how we use the tool (it’s a group effort). Applying Agile Tools and processes for remote teams is a skill, a craft to master. We are improving your craft and career skills to build effective, high morale remote teams. And we are improving your organizational capabilities to deliver compelling products.
This is not a “nice to have”. Its not an overstatement to call effective remote teams capabilities and global talent pools “essential” to compete in the digital economy and Industry 4.0.
Agile Manifesto Values
Source – https://en.wikipedia.org/wiki/Agile_software_development
| AGILE Manifesto 4 VALUES | Relevance to Effective Remote Teams |
| Individuals and interactions ARE VALUED over processes and tools | With remote teams we need to make a conscious effort to interact with each other one-on-one. Without talking frequently, we fail each other and fail the team. Team results matter more than individual results. Do the processes and tools, but only as they benefit the team. Don’t over obsess or over invest in tools for the sake of tools |
| Working software ARE VALUED over comprehensive documentation | Software will be used. Documentation is rarely read. Do the docs, but don’t over invest |
| Customer collaboration ARE VALUED over contract negotiation | Yes, collaborate with customer. More collaboration is better, focus on the problems, avoid dictated solutions. Do a plan of record. Push new requests into the next dev cycle (this mostly eliminates mission creep and avoids failed projects) |
| Responding to change ARE VALUED over following a plan | Keep projects short. Avoid mission creep. Maintain a roadmap to capture future requests. Respond to change by prioritizing next project/release rather than altering the current project WIP. In remote teams, communication is more important than ever. Stable projects reduce the risk of crossed wires and mis-communication. Especially important to remote teams. |
Agile 12 principles
| AGILE 12 Principles | Relevance to Effective Remote Teams |
| Customer satisfaction by early and continuous delivery of valuable software | Project-related connections, and interactions create that “picture of success” we are wired for, this is essential for remote teams. Frequent deliveries and continuous feedback are healthy. avoiding interaction and hiding behind a monitor is not healthy. suggest – a customer feedback tool (like a message box) that whole team can view (and respond to customer every time). Another opportunity to interact with customer |
| Welcome changing requirements, even in late development. | more customer interaction is healthy. Use short releases and roadmap. Show customers you listen and take action. Set reasonable expectations and clearly show customers that you deliver on commitments (customers will interact more, not less) |
| Deliver working software frequently (weeks rather than months) | use short releases to avoid mid-project change of POR new requests got into the roadmap for next projects rather than disrupting current project. For any team, constant project changes lead to project failure. For remote teams, imperfect communications related to constant project significantly increase risk of project failure. |
| Close, daily cooperation between business people and developers | Being remote means reduced feedback. Morale and productivity improve when remote teams to know their work is relevant and valued This is all in addition to the business value of delivering the proper solution. We are wired to have pride in our work |
| Projects are built around motivated individuals, who should be trusted | Truer words have never been spoken. When we encounter lack of clear goals (or constantly changing goals), micromanagement, and low morale. These point to a failure in management. When scratch the surface we usually find cost control, internal rather than external/customer focusmicromanagement, weak functional mgt, top down mgthigh talent attrition, not great people/skills remaining For Remote teams, micromanagement, top-down project changes lead to imperfect communications; significantly increase risk of project failure. |
| Face-to-face conversation is the best form of communication (co-location) | For remote teams … use video conferencing, every time Morale matters, we are building a sense of place and purpose use video conferencing every time, including one-on-ones |
| Working software is the primary measure of progress | For remote teams, tools matter, regular builds, structured testing, consistent defect logging/resolution. |
| Sustainable development, able to maintain a constant pace | For any team, and especially remote teams, avoid the cycle of overload, then idleness. Agile avoids situations where work piles up and then lands hard on one or two team members without adequate time to complete. Agile task boards with short tasks, quick and consistent hand offs and end customer input (see the penny game). |
| Continuous attention to technical excellence and good design | Agile fast handoffs create more learning. For remote teams handing code from member to member increases interaction and learning even when people don’t share the same office |
| Simplicity—the art of maximizing the amount of work not done—is essential | Remote teams always face communication problems, keeping tasks simple, projects short, and avoiding changes makes remote team execution significantly more efficient |
| Best architectures, requirements, and designs emerge from self-organizing teams | This is essential. Knowledge work is complex. The people closest to the problem, immersed in the problem, will provide the optimal architectures, requirements, designs and end user interactions Top down management simply lacks the knowledge. |
| Regularly, the team reflects on how to become more effective, and adjusts accordingly | Healthy teams are OK to celebrate mistakes, learn and improve. BUT this requires a “team first” meritocracy. Its doesn’t work well with an “individual first” meritocracy, or no meritocracy. |
I did product management and program management before Agile had been conceived or published. My on-the-job training involved user groups (customers). They gave me product feedback. I wrote these down for the Developer teams; they looked a lot like User-Stories.
I learned that long duration projects failed more frequently than short projects. We broke big projects into smaller, shorter, consistently successful short projects (aka. Sprints).
And even before agile, we had remote people working in other offices, contractors, partners and the like. These are not new problems, and craftsmanship to solve these problems is getting better all the time.